home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 570 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.6 KB
  1. Date: Thu, 21 Oct 93 19:32:12 -0400
  2. From: "Nicholas S Castellano" <entropy@terminator.rs.itd.umich.edu>
  3. To: sjg
  4. In-Reply-To: sjg@phlem.ph.kcl.ac.uk's message of Thu, 21 Oct 93 16:17:44 +0100 <9310211517.AA10128@phlem.ph.kcl.ac.uk>
  5. Subject: It's feedback time! 
  6.  
  7.  
  8. >Ah well. Looks like there's a reason all those unix workstations have R4000
  9. >or Alpha processors in them then :-). I'll let you know how it works on an
  10. >040 early next year.
  11.  
  12. Heh...well on UNIX it's a lot simpler, all the library read() does is
  13. call the operating system, which then does the right thing...of course
  14. the internals of the read() call in UNIX are probably pretty hairy
  15. too..
  16.  
  17. Of course a faster processor doesn't hurt...but from what I hear the
  18. overhead difference in millions of single-byte reads() between a 68000
  19. and an '03 isn't as much as one would hope...
  20.  
  21. >Yes, I've heard of that. Doesn't it do things like bcopy the entire
  22. >execution space every timeslice though. It sounds *incredibly* slow. At
  23. >least, there ought to be an option for >020 processors.
  24.  
  25. Exactly.  Sounds slow to me too.  I agree, on processors where it
  26. isn't necessary to fake it it should be done properly.
  27.  
  28. Just a guess here, but it may be possible to do a non-blocking fork on
  29. a 68000 for shared-text programs without copying the whole thing in
  30. and out.  Whether anyone ever gets around to implementing any of this
  31. is of course still an open question ...
  32.  
  33. >> What problems have you had with signals?
  34. >
  35. >The error numbers were the annoying ones. There's a list below of what 
  36. >Ultrix defines and what MiNT defines. There's a fair amount of common
  37. >ground, but MiNT appears to 'double-up' its errors, ie: where Ultrix will
  38. >have 2 or 3 errors, MiNT has only the one, which is returned for all 2 or 3
  39. >cases.
  40. >
  41. >The signals are (mainly) annoying because I have problems understanding 
  42. >the function prototype definitions in the header files :-). I think they
  43. >actually map quite well across to unix.
  44.  
  45. Yeah they are kinda hairy...too bad cdecl doesn't decode ansi
  46. declarations (at least the version I have) and doesn't really deal
  47. with typedefs either...
  48.  
  49. >The following are defined by Ultrix. I've put the MiNT error numbers in
  50. >brackets after the Ultrix ones. There are other MiNT codes unsupported by
  51. >Ultrix after this list...
  52. >
  53. >
  54.  
  55. Thanks for the errno list.
  56.  
  57. >(1) Should be EBUSY ?
  58. >(2) Should be ESPIPE ? (why PIPE ?)
  59. >(3) MiNT defines it to be    /* invalid function number */ 
  60.  
  61. I'll look into these, i'm not sure offhand...
  62.  
  63. --entropy
  64.  
  65. --
  66. entropy -- it's not just a good idea, it's the second law.
  67. Personal mail:      entropy@gnu.ai.mit.edu
  68. MiNT library mail:  entropy@terminator.rs.itd.umich.edu
  69.  
  70.  
  71.